Lecture 3 — Scope, Objectives & Approaches

🎯 By the end of this lecture you will be able to…

Define the scope of a problem using delimitations, and distinguish it from limitations.
Write clear, measurable research objectives using action verbs.
Tell the difference between aim, objectives, and research questions.
Select an appropriate investigative approach for a given computing problem.

Think of your research like a construction project. The scope is the plot boundary — it tells everyone where your land ends. The objectives are the rooms you promise to build. The approach is your construction method. Skip any one and inspectors (examiners) will notice.

1Defining the scope

The scope states the boundaries of your study — exactly what you will and will not investigate. A well-drawn scope protects you: it stops scope creep, makes the project finishable, and pre-empts the examiner's question "why didn't you also do X?"

Delimitations vs. limitations — don't confuse them

	Delimitations	Limitations
What	Boundaries you choose	Constraints outside your control
Nature	Deliberate scoping decisions	Weaknesses you acknowledge
Example	"Only English-language tweets; only Android."	"The dataset had only 2,000 samples; GPU limits capped model size."

💡 Scope in action

Problem: Detecting toxic comments with machine learning.

Scope statement: "This study focuses on text-only comments in English from a single public forum dataset, classifying them as toxic or non-toxic. It does not address images, sarcasm detection, multilingual content, or real-time deployment."

Notice how the sentence after "does not" is doing the heavy lifting — it fences off entire directions so you're not judged for ignoring them.

Draw the fence. What's inside the boundary is your promise; naming what's outside pre-empts "why didn't you also do X?"

⚠️ Common pitfall: an invisible scope

Many students never state a scope, so their project silently expands until it's unfinishable — or an examiner asks "why no multilingual support?" and they have no defensible answer. State your boundaries explicitly and early.

2Writing objectives (and the aim above them)

There's a small hierarchy here. Keep the three levels distinct:

Aim — one broad sentence: the overall purpose. "To improve phishing detection on temporally-novel emails."
Objectives — 3–5 concrete, measurable steps that together achieve the aim.
Research questions — the questions your objectives answer (from Lecture 1).

Objectives live and die by their verbs

Objectives must use action verbs you can evidence. Avoid fuzzy verbs like understand, explore, study, know — you can't prove them. Prefer design, implement, measure, compare, evaluate, classify, quantify.

💡 Aim → objectives, done well

Aim: To assess whether periodic retraining maintains phishing-detection accuracy over time.

To build a phishing classifier trained on 2022 emails.
To measure its F1 score on 2023 and 2024 emails.
To quantify the accuracy drop attributable to temporal drift.
To evaluate whether monthly retraining recovers the lost F1.

Each starts with a verb you can demonstrate, and each produces evidence. Together they deliver the aim.

Aim → objectives. One broad aim, split into a handful of measurable steps that each yield evidence — together they deliver the aim.

✅ Tip: the "Bloom's verb" ladder

Objectives at higher cognitive levels make stronger research. Rising order: identify → describe → apply → analyse → compare → evaluate → design. A project whose top objective is only "describe" is usually too shallow; aim to reach "compare/evaluate/design."

🤔 Pause & think

Which of these is a proper objective? (a) "To understand databases." (b) "To measure query latency of PostgreSQL vs. MongoDB on a 1M-row workload." Explain what's wrong with the weaker one.

3Investigative approaches for solutions

The approach is the strategy of inquiry — the overall style of investigation you'll use. Your problem type should drive your choice, not habit or convenience. In computing science, five approaches dominate.

① Experimental / empirical

Build something, run it under controlled conditions, and measure. Used for performance, accuracy, and comparison questions. Example: benchmarking two caching algorithms under identical load.

② Theoretical / mathematical

Reason with formal models, proofs, and analysis. Used to prove correctness, complexity bounds, or impossibility results. Example: proving an algorithm runs in O(n log n) worst case.

③ Constructive / design-science ("build & evaluate")

Design a novel artefact (algorithm, system, tool, framework) and demonstrate it solves the problem. The dominant approach in systems and software engineering. Example: designing a new scheduler and showing it reduces tail latency.

④ Simulation / modelling

When the real system is too large, costly, or dangerous to test directly, model it and run simulations. Example: simulating 10,000 IoT nodes to study a routing protocol you can't physically deploy.

⑤ Qualitative / survey / case study

Study people and practices — how developers use a tool, why teams adopt DevOps — through interviews, surveys, or observation. Common in HCI and software-engineering research. Example: surveying 200 developers on code-review pain points.

If your question is about…	Best-fit approach
"Which is faster / more accurate?"	Experimental / empirical
"Is this always correct / how complex?"	Theoretical / mathematical
"Can we build a better X?"	Constructive / design-science
"How would this behave at scale?"	Simulation / modelling
"How / why do people use this?"	Qualitative / survey / case study

Let the question pick the method. The type of question you ask points directly to the approach that can answer it.

📌 Note: mixed approaches are normal

Real projects often combine approaches. You might design a new algorithm (constructive), prove its complexity (theoretical), and benchmark it against baselines (empirical) — all in one thesis. Choose the primary approach your main question demands, then add others as support.

🤔 Your turn

For each, name the best approach: (a) "Does my new compression algorithm guarantee no data loss?" (b) "Do users find dark mode less tiring?" (c) "Which of three load balancers handles bursts best?"

✅ Check your understanding

1. A reviewer asks "is 'the dataset only had 2,000 images' a delimitation or a limitation?"

A limitation — it's a constraint outside your control that weakens the study. A delimitation would be a boundary you chose on purpose, e.g., "we deliberately used only grayscale images."

2. Why is "To understand machine learning" a poor objective?

"Understand" is not measurable or demonstrable — you can't produce evidence that proves it or a metric that tests it. Replace it with an action verb tied to evidence, e.g., "to compare the accuracy of three ML models on dataset X."

3. Match: "Prove that consensus is impossible under these failure assumptions." Which approach?

Theoretical / mathematical. Proving an impossibility result requires formal reasoning and proof, not experiments — you cannot benchmark your way to "impossible."

4. From "Your turn": name the approaches for (a), (b), (c).

(a) Theoretical — guarantees need proof. (b) Qualitative/experimental with users — perceived tiredness is measured via a user study. (c) Experimental/empirical — controlled benchmarking under burst load.

🧠 Key takeaways

Scope draws the boundary of your study; state explicitly what you will not do.
Delimitations are boundaries you choose; limitations are constraints you're stuck with.
An aim is one broad purpose; objectives are 3–5 measurable steps that achieve it — written with action verbs.
Avoid fuzzy verbs (understand, explore); use evidenceable ones (measure, compare, design, evaluate).
Let the question type pick the approach: empirical, theoretical, constructive, simulation, or qualitative — and mix when needed.

← PreviousCriteria of a Good Research Problem Next →Data Collection, Analysis & Instrumentation

Research Methodology in CS (CSEG3060) · Unit I · Lecture 3 · Dr. Mohsin Furkh Dar · UPES Dehradun